same domain to an entirely declarative 
planning system (ASPEN) was investi- 
gated, and, with some translation, 
much of the procedural knowledge en- 
coding is amenable to declarative 
knowledge encoding. 

The approach was to compose transla- 
tors from the core languages used for 
adapting MAGPEN, which consists of 
Europa and APGEN. Europa is a con- 
straint-based planner/scheduler where 
domains are encoded using a declarative 
model. APGEN is also constraint-based, 
in that it tracks constraints on resources 
and states and other variables. Domains 
are encoded in both constraints and 
code snippets that execute according to 
a forward sweep through the plan. Eu- 
ropa and APGEN communicate to each 
other using proxy activities in APGEN 
that represent constraints and/or to- 
kens in Europa. The composition of a 
translator from Europa to ASPEN was 
fairly straightforward, as ASPEN is also a 
declarative planning system, and the 


specific uses of Europa for the MER do- 
main matched ASPEN’s native encoding 
fairly closely. 

On the other hand, translating from 
APGEN to ASPEN was considerably 
more involved. On the surface, the 
types of activities and resources one en- 
codes in APGEN appear to match one- 
to-one to the activities, state variables, 
and resources in ASPEN. But, when 
looking into the definitions of how re- 
sources are profiled and activities are 
expanded, one sees code snippets that 
access various information available 
during planning for the moment in 
time being planned to decide at the 
time what the appropriate profile or ex- 
pansion is. APGEN is actually a forward 
(in time) sweeping discrete event simu- 
lator, where the model is composed of 
code snippets that are artfully inter- 
leaved by the engine to produce a 
plan/schedule. To solve this problem, 
representative code is simulated as a de- 
clarative series of task expansions. 


Predominantly, three types of proce- 
dural models were translated: loops, if- 
statements, and code blocks. Loops and if- 
statements were handled using controlled 
task expansion, and code blocks were 
handled using constraint networks that 
maintained the generation of results 
based on what the order of execution 
would be for a procedural representation. 

One advantage with respect to per- 
formance for MAPGEN is the use of 
APGEN’s GUI. This GUI is written in 
C++ and Motif, and performs very well 
for large plans. 

This work was done by Gregg R Rabideau, 
Russell L. Knight, Matthew Lenda, and Pierre F. 
Maldague of Caltech for NASA’s Jet Propulsion 
Laboratory. Further information is contained 
in a TSP (see page 1 ). 

The software used in this innovation is 
available for commercial licensing. Please con- 
tact Dan Broderick at Daniel.F.Broderick@- 
jpl.nasa.gov. Refer to NPO-48597. 


@ Support Routines for In Situ Image Processing 
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This software consists of a set of appli- 
cation programs that support ground- 
based image processing for in situ mis- 
sions. These programs represent a 
collection of utility routines that perform 
miscellaneous functions in the context of 
the ground data system. Each one fulfills 
some specific need as determined via op- 
erational experience. The most unique 
aspect to these programs is that they are 
integrated into the large, in situ image 
processing system via the PIG (Planetary 
Image Geometry) library. They work di- 
rectly with space in situ data, understand- 
ing the appropriate image meta-data 
fields and updating them properly. The 
programs themselves are completely 
multimission; all mission dependencies 
are handled by PIG. 

This suite of programs consists of: 

• marscahv: Generates a linearized, epi- 
polar aligned image given a stereo pair 
of images. These images are optimized 
for 1-D stereo correlations. 

• marscheckcm: Compares the camera 
model in an image label with one de- 
rived via kinematics modeling on the 
ground. 

• marschkovl: Checks the overlaps be- 
tween a list of images in order to deter- 
mine which might be stereo pairs. This 
is useful for non-traditional stereo im- 


ages like long-baseline or those from 
an articulating arm camera. 

• marscoordtrans: Translates mosaic co- 
ordinates from one form into another. 

• marsdispcompare: Checks a Left— >Right 
stereo disparity image against a 
Right— >Left disparity image to ensure 
they are consistent with each other. 

• marsdispwarp: Takes one image of a 
stereo pair and warps it through a dis- 
parity map to create a synthetic oppo- 
site-eye image. For example, a right 
eye image could be transformed to 
look like it was taken from the left eye 
via this program. 

• marsfidfmder: Finds fiducial markers 
in an image by projecting their approx- 
imate location and then using correla- 
tion to locate the markers to subpixel 
accuracy. These fiducial markets are 
small targets attached to the spacecraft 
surface. This helps verify, or improve, 
the pointing of in situ cameras. 

• marsinvrange: Inverse of marsrange — 
given a range file, re-computes an XYZ 
file that closely matches the original. 

• marsproj: Projects an XYZ coordinate 
through the camera model, and re- 
ports the line/sample coordinates of 
the point in the image. 

• marsprojfid: Given the output of 
marsfidfmder, projects the XYZ loca- 


tions and compares them to the found 
locations, creating a report showing 
the fiducial errors in each image. 

• marsrad: Radiometrically corrects an 
image. 

• marsrelabel: Updates coordinate sys- 
tem or camera model labels in an 
image. 

• marstiexyz: Given a stereo pair, allows 
the user to interactively pick a point in 
each image and reports the XYZ value 
corresponding to that pair of locations. 

• marsunmosaic: Extracts a single frame 
from a mosaic, which will be created 
such that it could have been an input 
to the original mosaic. Useful for creat- 
ing simulated input frames using dif- 
ferent camera models than the origi- 
nal mosaic used. 

• merinverter: Uses an inverse lookup 
table to convert 8-bit telemetered data 
to its 12-bit original form. Can be used 
in other missions despite the name. 

This work was done by Robert G. Deen, 
Oleg Pariser, Mathew C. Yeates, Hyun H. 
Lee, and Jean Lorre oj Caltech Jor NASA’s Jet 
Propulsion Laboratory. Further information 
is contained in a TSP (see page 1 ). 

This software is available for commercial li- 
censing. Please contact Dan Broderick at 
Daniel.F.Broderick@jpl.nasa.gov. Refer to 
NPO-47728. 


26 


NASA Tech Briefs, June 2013 


